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Abstract 

This report describes a high-level formal specification of a human-computer interface. A 
typical window manager is modeled. Previous work is reviewed and the Aslan specification 
language is described. Top-level specifications written in Aslan for a library and a multiwindow 
interface are discussed. 
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J. Introduction 


1.1 Organization of the Paper 

This paper documents an attempt to formally specify a multiwindow user interface. The 
paper is organized as follows: 

Section I briefly reviews the foundation laid in last summer’s work and discusses motivar 
tions and expected results of using formal specification techniques on user interfaces. Section 
II 1 introduces the Aslan formal specification language through the example in Appendix A. 
Section III is a detailed look at an abstract specification of a typical multiwindow interface. 
The formal specification discussed in Section III is in Appendix B. Finally, Section IV contains 
concluding remarks and recommendations, 

1.2 Specification and Verification Terminology 

Specifications are statements about the functionality of a system. Specifications express 
what is a system is to accomplish, not how it is to do it. In this paper, formal specifications 
are assertions about the behavior of a system. Critical correctness criteria are assertions that 
the specification and all refinements and implementations are to satisfy. Formal verification 
techniques demonstrate that implementations satisfy their specifications. In addition, it is 
useful to show that specifications meet their critical correctness criteria. This is sometimes 
called design verification. Neumann explains [12]: 

Formal verification has often been talked about as a technique for demonstrating 
consistency between code and assertions about that code, in some cases between 
code and specifications. Somewhat less popular has been the easier notion of using 
formal verification to demonstrate that a set of formal specifications is consistent 
with its formally axiom ati zed requirements, i.e., carrying out design verification. 

1.3 Previous Work 

This report describes a continuation of work on formalisms for user interface specification 
and design described in [1]. That work examined several recent research results in human- 
computer interaction (HCI) that may be applicable to NASA applications. One of the results 
examined was the formal specification of direct manipulation user interfaces for a secure military 
message system [7, 8 ], „ . . 

[1] also contains an introduction to formal specification and verification including objections 
to the approach and reasonable expectations. It was recommended that a pilot 6tudy using 
formal techniques on a small, well- defined piece of a user interface be done. The subsystem 
to be specified should have clear, high-level correctness properties that must be met. The 
specification given in Appendix B of this paper is the portion of a user interface that manipulates 
windows. The correctness property that must be maintained is that users are not allowed to 

‘The information in II.2 and Appendix A is based on a portion of a paper by the author and Daniel Stearns, 
“Using the Aslan specification language in undergraduate software engineering courses,” submitted to Computer 
Science Education , July 1990 
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move, close, or resize certain windows. This correctness property was derived from current 
interface prototypes developed at NASA KSC. 

Using formal specification techniques is costly. Benefits are realized when there are readily 
identifiable, critical correctness properties that must hold. This is the case for portions of 
proposed interfaces to shuttle and space station software. 

Further, it is not necessary to carry out formal specification and verification to their full 
extent to realize benefits. Finding an appropriate level of formality and analysis can result in 
systems that users can have a high degree of confidence in. To summarize [1, section IV.2.2]: 

The general goal is to lower expectations for formal specification - the goal isn’t 
necessarily provably correct software — but to specify important functionality and 
correctness criteria in a way that is reviewable by software engineers and integrates 
usefully in other software development efforts. 

1.4 Formal Techniques and the Development of User Interfaces 

As noted in [1], there is some controversy about the usefulness of formal specification and 
verification techniques in general. Because modern interfaces are visually complex and becoming 
more aural, some HCI researchers believe that prototyping and user interface management 
system (UIMS) axe the correct approach to interface specification and development. Fischer is 
a critic of formal specification of interfaces [6, p. 50,51]: 

Static specification languages have little use in HCI software design. First, de- 
tailed specifications do not exist. Second, the interaction between a system and its 
user is highly dynamic and aesthetic, aspects that are difficult, if not impossible, to 
describe with a static language. . . . A prototype makes it much easier and produc- 
tive for designers and users to cooperate because users do not have to rely on written 
specifications, which do not indicate an interface’s qualities. . . .Validation and ver- 
ification methods from other software domains have limited use in HCI. Formal 
correctness is crucial, but it is by no means a sufficient measure of the effectiveness 
and success of an HCI system. 

Fischer’s statements axe true for most interface development efforts. Formal techniques 
aimed at low level or aesthetic portions of user interfaces may not be productive. 

However, for critical aspects of NASA interfaces, such as alarm areas, critical correctness 
requirements axe apparent and easily expressed. By using techniques employed in the specifi- 
cation of secure systems, formal specification becomes a valuable approach. 

Further, it is possible to combine formal specifications of functionality with usability spec- 
ifications. Carrol and Rosson have studied the design process and recommend an iterative 
approach of developing and integrating functionality and usability specifications [5, p. 1]: 

Much has been said about this “usability” problem regarding current interface 
designs. Less has been said about how to solve the problem. ...we develop an ap- 
proach to the problem based on usability specifications: precise, testable statements 
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of performance goals for typical users carrying out tasks typical of their projected 
use of the system. 

1.5 Two Views of Specifications 

Most specification efforts target one of two goals: an executable specification (prototype 
system), or a proof that a specification meets critical correctness requirements (“design verifi- 
cation”). HCI specification are usually developed with the intent of having a prototype system 
that can be “checked for certain undesirable properties” [8, p. 211]. Because these speci- 
fications are to result in realistic prototypes, it is necessary to specify low-level events such 
as mouse clicks and beeps. Not surprisingly, it is not feasible to combine a huge quantity of 
implementation details with design verification of the specification. 

The approach explored in this paper is to write abstract specifications and critical correct- 
ness requirements for a portion of a user interface without getting bogged down in implemen- 
tation details. High-level specifications have been very successful in the field of secure systems. 
The formal specifications for these systems are shown to be consistent with their critical cor- 
rectness criteria without becoming bogged down in implementation details. For example, in a 
short, high-level specification, Kemmerer shows fundamental flaws in a cryptosystem [10]. 

Although Jacob focuses on executable specifications and prototyping, he briefly discusses 
extensions to his techniques [8, p. 237]: 

In designing a secure message Bystem, it is desirable to prove assertions about 
the security of the system formally. Such proofs are usually based on a formal 
specification of the system (with the proviso that the final software and hardware 
correctly implement the specification). This approach has not generally been used 
at the user interface level, but, if one had a formal specification of the user interface, 
it would be possible to provide proofs about the user interface. 

1.6 Testing vs. Proving Specifications 

A common and persistent criticism of formal specification and verification is that the quan- 
tity of proofs that must be done is overwhelming, a formal specification and statement of 
correctness, it is possible to gain insights into the system and confidence in the specification 
without performing proofs. The informal analysis of a formal specification can be a valuable 
technique for communication between software engineers. 

More formally, symbolic execution tools have been developed [11]. Specifications can then 
be tested against correctness requirements. Testing specifications allows software engineers to 
play what-if games with the specification and may result in the discovery of system states that 
do not satisfy the correctness requirements. 

These tools have been successfully used in the development of secure systems. Kemmerer 
explains the use of the Inatest tool on a cryptosystem specification [10, p. 453]: 

With the Inatest tool, it is possible to introduce assumptions about the system 
interactively, execute sequences of transforms, and check the results of these execu- 
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tions. This provides the user with a rapid prototype for testing properties of the 
cryptographic facilities . . . 
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II. Formal Specification 


II. X The Aslan Specification Language 

Software engineers’ lack of exposure to formal specification systems is particularly disturbing 
in light of increasing dependence on critical software systems. Neumann describes examples of 
problems with specifications in four application areas: human safety, reliability, security, and 
user interfaces [12]. Neumann concludes (emphasis added): 

There are many contributions that good software engineering practice could 
have made to the prevention or minimization of these and many other problems. 

In particular, the sound use of system structuring, specification languages capable 
of meaningful abstraction, and rigorous analysis of specifications could all have bad 
significant effects. 

The Aslan formal specification language is a partial solution to the above problem. Software 
engineers can use Aslan to formally specify complex systems and develop their specifications 
through arbitrary levels of abstraction. When a specification is passed through the Aslan 
Language Processor (ALP), software engineers receive a set of correctness conjectures. 

The following sections describe features of Aslan using a specification of a library as an 
example. The library example has been used in many formal specification workshops. A library 
specification written in the InaJo language appears in [11]. 

II.2 The Aslan Approach 

The Aslan language is built on first order predicate calculus. Systems being specified are 
thought of as being in states, defined by the values of the system variables. Logical assertions 
axe used to define the critical correctness requirements that must hold in every state and those 
that must hold between two consecutive states. The former are state invariants, while the latter 
are constraints on state transitions. 

To prove that a specification satisfies its invariant and constraints, the ALP generates cor- 
rectness conjectures. Correctness conjectures are logical statements whose proof ensures the 
correctness of the specification with respect to the invariant and c ons traint. 

Appendix A contains a high-level specification of a library. Although the library could be 
further specified through more detailed levels of specification, only the top-level specification 
will be e xamin ed here. 

The state variables for this system appear in the VARIABLE section of the specification. 
Library is a variable whose type is a collection of Book. At this level. Book is left as an 
unspecified type. A state variable Checked.Out maps each book into the boolean domain, 
while Number Jut maps library users to the the number of books they have checked out. 

The specification contains an initial assertion defining possible starting states of the library. 
This assertion states that the library is initially empty, that no users have books out, and that, 
indeed, no books are checked out. 
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The library specification contains an invariant assertion to specify the essential properties 
that the system must have. The invariant states that 

• when a book is checked out, it cannot be available. Similarly, an available book cannot 
simultaneously be checked out. 

• the limit on the number of books checked out by any user is enforced 

• no user has more than one copy of the same book checked out 

Clearly, we want the initial state of the system to fulfill the invariant. The ALP will generate 
a logical implication that 

initial — ► invariant 

The particular correctness conjecture generated is 


Library = EMPTY 

ft FORALL u: User (Number .Books (u) * 0) 
ft FORALL b: Book ('Checked.Out(B)) 

FORALL b :Book( b ISIN Library -> 

Checked.Out(b) ft 'Available (b) 

| 'Checked.Out(b) ft Available(b)) 
ft FORALL u:User ( Number .Books (u) <= Book_Limit) 
ft FORALL u:User ,bl , b2:Book( 

Checked_0ut_To(u, bi) 
ft Checked.Out.ToCu, b2) 
ft Copy _0f (bl, b2) 

-> bl ■ b2) 


It is up to the specifier, possibly with the help of a theorem prover, to prove the above 
correctness conjecture. 

An empty library is not very interesting. The specification must define how the library can 
expand; that is, how the library can change from a current (‘old’) state to a new state in which 
more books are present. 

Allowable state changes are specified as transitions. An Aslan transition consists of a 
precondition (ENTRY) and a postcondition (EXIT). Transitions in the library example have only 
postconditions. The ALP assumes that omitted preconditions are true. 

The Add_A_Book transition allows the library to expand. Because Add_A_Book does not have 
an entry assertion, it can be applied at any time. The exit assertion states the effect the 
application of the transition has on the state variables. It asserts that 
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• the user adding the book must be a member of the library staff, 

• and assuming the user is a staff person and the book isn’t already in the library (the 
apostrophe is the Aslan notation for ‘old value’), 

• the book is added to the library 

• the book is not checked out 

• and in particular, this book has never been checked out 

How can the specifier be assured that the Add_A_Book transition meets the correctness 
requirements embodied in the invariant? It must be proved that if the invariant holds in the 
current (old) state, and the transition is applied, then the invariant will hold in the new state. 
That is, 


invariant’ & entry’ & exit — ► invariant 

Note that in the antecedent, the invariant and the entry assertion are evaluated in the old 
state. The exit assertion and the consequent are evaluated in the new state. 

Aslan specifications can be made up of several levels of abstraction. Given a multilevel 
specification, the ALP generates additional correctness conjectures that ensure that types, 
variables, and transitions are properly refined, and that the correctness requirements are met 
at every level of abstraction. Details are found in [4]. 

Ideally, Aslan should be used to specify increasingly concrete levels of abstraction. The 
resulting specification would be a high level specification defining the system as an abstract 
data type, followed by intermediate levels leading to a low level specification close to code level. 
In this most detailed specification level, the transitions’ entry and exit assertions become the 
the pre- and postconditions of programming language level procedures which implement them. 

II. 3 A Specifier-friendly Feature 

Expressions in Asian look like first order logic assertions for a simple reason: the techniques 
and expressive power of first order logic can be used to prove correctness conjectures. 

Unfortunately for specifiers with a programming background, the semantics of first order 
logic are not the same as those of procedural programming languages such as Pascal and C. 
Consider an alternate version of the Return transition: 


TRANSITION Retum(B: Book) 

EXIT 

Checked_Out’ (B) -> Checked. Out (B) ■ FALSE 

& Number.Books (Responsible ’ (B)) ■ 

Number.Books (Responsible ' (B) - 1) , 
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The above exit assertion is written in a purely ‘logical’ form. Recall that the ALP will 
construct a correctness conjecture whose proof ensures the invariant holds after the application 
of Return: 


FORALL b:Book (b ISIN Library’ -> 

Checked.Out ’ (b) ft 'Available ’ (b) 

| "Checked.Out ’ (b) ft Available’ (b)) 
ft FORALL u:User (Number.Books’ (u) <* Book.Limit) 
ft FORALL u:User ,bl , b2:Book( 

Checked.Out .To ’(u, bl) 
ft Checked.Out .To’ (u, b2) 
ft Copy_0f(bl, b2) 

-> bl = b2) 
ft 

Checked.Out’ (B) -> Checked.Out (B) * FALSE 

ft Number.Books (Responsible * (B)) * 

Number.Books (Responsible ’ (B) - 1) 

-> 

FORALL b:Book (b ISIN Library -> 

Checked.Out (b) ft 'Available(b) 

| 'Checked.Out (b) ft Available(b)) 
ft FORALL u:User (Number.Books (u) <= Book_Limit) 
ft FORALL u:User,bl, b2:Book( 

Checked_Out_To(u, bl) 
ft Checked_Out_To(u, b2) 
ft Copy_0f(bl, b2) 

-> bl = b2) 

It is a simple paper and pencil exercise to show that the conjecture generated cannot be 
proved. In particular, 

• The new values of Available and Checked_Out_To are mentioned in the consequent in- 
variant. Nothing can be proved about the new values of Available and Checked_Out_To. 
Neither variable was mentioned in the exit assertion of Return, and the antecedent in- 
variant only relates old values of the state variables. 

• Because the exit assertion was written as a logical implication, we have not specified 
what will happen when Checked.Out’ (B) is false. In particular, if the book B was not 
checked out, the new value of Checked.Out (B) could be true or false. Also, the values of 
Checked_Out for books other than B are unspecified! 
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• Similarly, we have not specified the new values of Number .Books for all users not responsi- 
ble for the particular book B being returned. In particular, the new value of Number3ooks 
for such users could be any integer. 

These differences between the semantics of logic and those of programming languages have 
caught professional specification writers by surprise [14]. 

The Aslan language provides constructs that operate like programmers tend to think logical 
operations should operate. Corresponding to logical implication is the Asian IF-THEN~ELSE~FI , 
corresponding to disjunction is the ALT (alternative) statement, and corresponding to equality 
is the BECOMES statement. Details are found in [3, 4]. 

In addition, Aslan supplies the implicit ‘no changes’ for variables mentioned in the invariant 
and constraint, but not mentioned in a particular transition. 

These language features allow specifiers to write specifications in a more natural way. Read- 
ers should compare the Return transition above with the version in the appendix. 

Preliminary work on extending Aslan to facilitate specification of real-time systems is 
documented in [2]. 



III. Specification of a Multiwindow User Interface 


III.l Overview 

Appendix B contains an Aslan specification of an interface commonly provided by window 
managers running on the X window system [9, 13, 15]. Windows can be created, deleted, 
opened, closed, resized, moved, brought to the foreground, and be made the target of user 

input. 

The specification has one feature not usually found in multiwindow interfaces: dedicated, 
reserved (“special”) windows that cannot be moved, closed, or covered. Displays proposed for 
shuttle ground support software will have such areas. 

This specification was written to be an abstract description of the operations provided by a 
window manager to a user. Note that pixels and mice, usually associated with such interfaces, 
are not mentioned. It is sometimes hard to determine an appropriate level of abstraction 
for a top-level specification. A guideline is that the most abstract specification be such that 
critical functionality and correctness requirements can be expressed in a form that is readily 
understandable and easily manipulable. In addition, top-level specifications should not restrict 
possible implementations and refinements. 

Although only a top-level specification of the interface is provided, it is dear that more 
detailed levels of refinement could introduce implementation details such as pixels and mice. 

Each major syntactic unit of the specification will be discussed in turn. Sections III.2 
through III. 8.8 refer directly to Appendix B. The following lexical convention is used: con- 
stants and Aslan keywords are uppercase, type identifiers begin with uppercase, variables and 
definitions are lower case. 

111.2 Types 

Six unspecified types are declared to represent dasses of system objects that require no 
elaboration at this level. For example, Processes can be assodated with Windows, however at 
this level of abstraction it is not important how either is implemented. Further, how windows 
look on the screen (their Representations, Sizes, and Locations) are deferred. 

The Display .Levels type represents the stacking level of windows on the screen. It is 
tempting to define Display_Levels as a synonym for integer. This would restrict possible 
implementations. As discussed in EU.3, it is only necessary that Display .levels have a less- 
than-or-equal ordering. 

The state of a window is a simple enumerated type. The layout of a window is a structure 
of three fields: a location, size, and a representation. As discussed in section HI.4, windows 
have a layout for when they are open, and another layout (an icon) for when they are dosed. 
Finally, the contents of the current screen is of type Displays - a set of window layouts. The 
current display along with current stacking levels for the active windows defines the look of the 
screen. 

111.3 Constants 

Constants are unchanging mappings. For example, INITIAL_OPEN_LAYOUT assodates a de- 
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fault look for windows opened for processes. With INITIAL.CLOSED .LAYOUT and INITIAL-STATE, 
the window manager determines the look of a window when it is created for a process. 

OVERLAPS is an important relation that maps two layouts to true or false. The intent is that 
refinements of OVERLAPS will check to see if any of the first layout overlaps the second. This 
constant relation is useful in determining if windows are on the screen (overlap the BACKGROUND) 
and if they would obscure a restricted window. 

LESS_OR_EQUAL is similar to OVERLAPS. This boolean constant maps window stacking levels. 
If Display_Levels is subsequently refined to be the integers, this constant may turn into 
nothing more than <. 

SPECIAL is a boolean function that determines if a window is restricted. It is made a 
constant in this specification so that the mechanisms for making windows restricted or not can 
be omitted. It is reasonable that SPECIAL could be changed to be a state variable and state 
transitions for its manipulation be added. 

111.4 State Variables 

The value of the state variables determine the state of the interface. These values are 
changed by the application of the state transitions discussed in section III. 8 . 

Windows are created for processes. The mapping of processes to windows is represented in 
process. When a process is bound to a window, the window will inherit the initial open and 
closed layouts from the process. These layouts (open_layout, closed-layout) can be changed 
by the resize and move state transitions. Associated with each window is also a stacking level 
display-level. 

The layouts currently active on the screen axe in display. The window selected to receive 
input is determined by the value of input_focus. 

111.5 Definitions (Macros) 

Aslan definitions are macros used to make state transitions more understandable. Eight 
definitions are given to represent mundane events such updating the display and changing layout 
fields. 

to.top .level is interesting because it specifies that the stacking level of its argument is to 
be less than all other windows, and that the relationship between other windows should remain 
as it was before the argument was made uppermost window. 

There are two things to note. First, to_top_level may be restricting future implemen- 
tations. It is not necessary for the argument’s stacking level to be strictly less than that of 
all other windows, just that it be less than the level of all windows in its stack. That is, the 
topmost windows of independent stacks on the screen could have the same display .level. It 
is an interesting exercise to rewrite the definition to allow this. 

Second, although it is specified that the relationships of other windows remains as they were 
before the state transition, it is possible that the value of disp lay .level for each window has 
changed! This allows refinements and eventual implementations flexibility in assigning display 
levels - any implementation that has the argument window ending up on top, and doesn’t 
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rearrange the other windows meets this specification. 

set_location and set.size manipulate one field of a particular window’s current layout. 
Care is taken that other fields for this window, and layouts for other windows are unchanged. 

The update.display definitions specify the addition and deletion of layouts to the current 
display. 

III. 6 Initial Conditions 

The INITIAL assertion describes the state of the interface when the system is first brought 
up. An informal reading of the assertion is “nothing is on the screen, and all windows are 
inactive, and windows that are created for processes will be on somewhere on the screen. 

HI. 7 Critical Correctness Requirements 

The critical correctness requirements are expressed in the INVARIANT. This assertion is to 
be true when the system is started, and continue to hold in every state the system can reach 
starting at the initial state and using the state transitions described in m.8. The assertion 
consists of three conjuncts. The first says that every layout on the screen has to be associated 
with an active window. The second asserts that every current layout must be at least partially 
on the screen. The third states that restricted windows axe not covered. 

III. 8 State Transitions 

The following subsections describe the eight state transitions. Since none of the transitions 
have explicitly stated ENTRY assertions, there are no restrictions on when the transitions can be 
applied. This corresponds to typical window managers - it is possible, for example, to attempt 
to dose windows at any time. 

Although there are no restrictions on when the transitions can be applied, it is not always 
the case that applying them has any effect on the state of the system. For example, most 
window managers will allow a user to close an already dosed window. From the user’s view, 
there is no change in the state of the display. 

The specifications for the state transitions are written with this in mind. The style used is 
as follows: an exit assertion is a disjunct of two dauses joined by the Aslan ALT operator. The 
first clause specifies the effect of the state transition when variables are changed (the dosing of 
an open window, for example) and the second clause spedfies that no variables change. 

The ALT operator is logical disjunction augmented by statements spedfying that unmen- 
tioned state variables do not change. These statements are generated automatically by the 
ALP [3, 4]. 

When reading the transitions it is important to pay careful attention to the use of the 
old- value operator (apostrophe). The following sections will focus on the first disjunct of each 
transition’s exit assertion. 

III.8.1 Window Closing (Iconifying) 

To close a window w, it is necessary that w be open, that it is not a restricted window, that 
w’s new state is dosed (and that the states of other windows axe unchanged), that w’s open 
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layout is taken off the screen and replaced by its icon, and that the icon not be hidden. 

111.8.2 Window Opening 

open.window is symmetric to close_window. 

111.8.3 Window Destruction 

To destroy a window w, it is necessary that w active before the state transition and unused 
afterwards, that v is not a restricted window, and that the layout of w be removed from the 
screen. 

111.8.4 Window Creation 

Windows are created for and associated with processes, lb create a window for process p it 
is necessary that there exists a window w that was inactive before the state transition and will 
become active. This window will inherit its initial state and layouts from p. v will be associated 
with p, and v’s current layout will be added to the display uncovered by other windows or icons. 

111.8.5 Shifting Input Focus 

This transition assumes that only one window at a time can be the target of user input. It 
is a simple transition that checks that only active windows can receive input. 

111.8.6 Moving Windows 

The move transition looks more complicated than it is. There are two symmetric cases for 
when the window to be moved, w, is open and closed. In either case, u cannot be a restricted 
window and the current display is modified. If w’s state is open then its location is changed, 
v must still be on the screen, and w cannot overlap any special windows. The case when v is 
closed is symmetric. 

111.8.7 Window Resizing 

This transition states that only ordinary, open windows can be resized. In addition, a 
window cannot be resized to overlap a restricted window. 

111.8.8 Window Restacking 

To bring an active window v to the foreground, the display must be changed, and the act 
of bringing w to the foreground must not overlap a restricted window. 
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IV. Concluding remarks 


This paper has discffsfed formal specification of user interfaces. The particular approach 
taken was to construct an abstract, state-machine model of the interface using the Aslan 
specification language. Emphasis was placed on defining essential functionality and critical 
correctness requirements without introducing implementation details. 

The resulting specification defines the functionality of a typical window manager (Appendix 
B). The specification can be the foundation of several further activities: 

• The correctness conjectures generated by the Aslan language processor could be proved. 
Successful proofs would show that the specification satisfies its critical correctness criteria. 

Failed attempts to prove correctness conjectures have lead to new insights into the system 
being specified. Failed proofs can show misunderstandings in functionality, inconsistency, 
and incompleteness. These insights can be especially valuable to software engineers as 
they work toward defining essential functionality and correctness of a system. 

• The specification can be expanded. It would be useful to refine the top-level specification 
into lower, more detailed specifications. A challenge is to refine the specification down 
to an implementation level at which objects such as pixels, mouse dicks, and scroll- 
bars are used. New techniques would have to be developed to maintain readability and 
understandability while handling the amount of detail at low levels. 

• The specification could serve as inspiration for a spedfication of a particular part of the 
proposed shuttle/space station ground software. This is a promising area for further 
research. After informal requirements for, say, protected alarm areas on screens are 
developed, an effort should be made to formally spedfy their actions and correctness 
requirements. 

• The specification could be tested. A symbolic execution tool for Aslan specifications 
should be constructed. 

Formal specification of user interfaces is not cost effective for most projects. However, for 
highly structured interfaces whose performance is critical (such as the NASA interfaces being 
developed) formal specification can play a valuable role in unambiguously defining functionality 
and providing confidence in meeting correctness requirements. There is considerable interest in 
formal techniques and proofs of correctness among developers of critical interfaces. 
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Appendix A 

Specification of A Library 


SPECIFICATION Library 
LEVEL Top.Level 

TYPE 

User, 

Book, 

Book.Title, 

Book.Author , 

Book.Collection IS SET OF Book, 

Titles IS SET OF Book.Title, 

Pos.Integer IS TYPEDEF irINTEGER (i>0) 

CONSTANT 

Title(Book) :Book_Title, 

Author (Book) :Book_Author, 

Library.Staf f (User) : BOOLEAN , 

Book.Limit :Pos_Integer 

DEFINE 

Copy_0f (B1 ,B2:Book) : BOOLEAN == 
Author(Bl) = Author(B2) 

& Title(Bl) = Title(B2) 


VARIABLE 

Library : Book.Collection , 
Checked. Out (Book) : BOOLEAN, 
Responsible(Book) :User, 
Number .Books (User) : INTEGER, 
Never .Out (Book) : BOOLEAN, 


DEFINE ...... . 

Available (B : Book) : BOOLEAN 

B ISIN Library ft " Checked. Out (B) , 
Checked_Out_To(U:User,B:Book) :BOOLEAN *= 
Checked.Out(B) 
ft Responsible (B)=U 
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INITIAL 


Library = EMPTY 

ft FORALL u:User (Number.Books (u) * 0) 
ft FORALL b:Book (*Checked_Out(b)) 

INVARIANT 

FORALL b:Book(b ISIN Library -> 

Checked.Out (b) ft "Available (b) 

I "Checked.Out(b) ft Available(b)) 
ft FORALL u:User(Number_Books(u) <= Book.Limit) 
ft FORALL u:User,bi,b2:Book( 

Checked_Out_To (u ,bl) 
ft Checked.Out .To (u,b2) 
ft Copy.Of (bl,b2) 

-> bl=b2) 

TRANSITION Check.Out (U : User ,B : Book) 

EXIT 

Available’ (B) 

ft Number.Books ’ (U) < Book.Limit 

ft IF FORALL Bl:Book (Checked.Out.To’ (U,B1) -> "Copy.Of (B.Bl)) 
THEN 

Number.Books (U) BECOMES (Number_Books ’ (U) + 1) 
ft (Checked_Out(B) BECOMES TRUE) 
ft (Responsible (B) BECOMES U) 
ft (Never.Out(B) BECOMES FALSE) 

FI 

TRANSITION Return(B :Book) 

EXIT 

( IF Checked.Out’ (B) 

THEN Checked.Out (B) BECOMES FALSE 

ft Number.Books (Responsible ’ (B)) 

BECOMES (Number.Books (Responsible’ (B)) - 1) 

FI) 

TRANSITION Add.A.Book (U : User ,B : Book) 

EXIT 

( IF Library.Staff (U) 
ft B "ISIN Library’ 

THEN Library = Library’ UNION <B> 
ft Checked.Out (B) BECOMES FALSE 
ft Never.Out(B) BECOMES TRUE 
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FI) 


TRANSITION Remove_A_Book(U :User ,B : Book) 

EXIT 

(IF Library.Staff (U) 

& Available’ (B) 

THEN Library » Library’ SET.DIFF {B> 
FI) 


END Top .Level 
END Library 



Appendix B 

Specification of a Multiwindow Interface 


w 


SPECIFICATION window.interface 

INHIBIT /* do not produce correctness conjectures *1 
LEVEL Top.Level 

/* Brent Auernheimer — July 1990 

This is a high-level specification written using the Aslan 

specification language of a window-based 

user interface. Mice are not explicitly mentioned. 

Note that a * (‘prime’) is the old-value operator. That is, 
is x is a variable, then x’ represents its value before the 
application of a transition. An unprimed x represents the 
new-value of x. 

This user interface is typical of window managers running 
on X. One added feature is SPECIAL windows 
which cannot be closed (iconif ied) , moved, or covered by 
other windows or icons . 

Notational conventions — alphanumeric tokens are lowercase 
except for the following: 

* Keywords and constants are uppercase. 

* Type identifiers begin with uppercase. 


TYPE 

Windows, Processes, Locations, Sizes, Representations, Display.Levels, 
States IS (OPEN, CLOSED, UNUSED), 

Layouts IS STRUCTURE OF 

(location: Locations, size: Sizes, rep: Representations), 

Displays IS SET OF Layouts 

CONSTANT 

NULL.PROCESS: Processes, 

INITIAL_OPEN_LAYOUT(Processes) : Layouts, 
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INITIAL_CLOSED_LAYOUT(Processes) : Layouts, 

INITIAL_STATE(Processes) : States, 

/* OVERLAPS is to be true if first argument overlaps the second */ 
OVERLAPS (Layouts, Layouts): BOOLEAN, 

BACKGROUND: Layouts, /* windows must overlap the background */ 
SPECIAL (Windows) : BOOLEAN, /* some windows cannot be covered */ 

/* the smallest display .level is the window closest to the top, 
the largest is the window buried the deepest */ 

LESS.OR.EQUAL (Display .Levels, Display.Levels) : BOOLEAN 


VARIABLE 

process (Windows) : Processes, 
open.layout (Windows) : Layouts, 
closed.layout (Windows) : Layouts, 
state(Windows) : states, 
input.f ocus (Windows) : BOOLEAN , 
display: Displays, 

display.level (Windows) : Display.Levels 


DEFINE 

/* DEFINitions are macros used to 


make state transitions easier to read */ 


to_top_level(w: Windows): BOOLEAN 

/* w becomes the topmost window . . . */ 

FORALL w2: Windows ( 

(w "= w2) 

-> LESS.OR.EQUAL (display .level (w), display.level (w2)) 
ft display.level (w) "« display.level (w2)) 

/* all other windows maintain their previous relationship *1 
ft FORALL wl, w2: Windows ( 

(wl "* w ft w2 '= w) -> ( 

(LESS.OR.EQUAL (display.level* (wl) , display.level* (w2)) 

-> LESS_OR_EQUAL(display_level(wl) , display.level (w2))) 
ft (LESS_0R_EQUAL(display_level’(w2) , display.level* (wl)) 

-> LESS_0R_EQUAL(display_level(w2) , display.level(wl))))) , 

/* note that square brackets are used to select fields from 
structure typed variables */ 

set_location(w: Windows, s: States, 1: Locations): BOOLEAN 
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((s = OPEN) 

-> FORALL wl: Windows ( 

(w * wl -> open.layout (w) [location] « 1 

ft open.layout (w) [size] * open.layout’ (w) [size] 
ft open.layout (w) [rep] * open.layout’ (w) [rep]) 
ft (w '= wl -> open.layout (wl) = open.layout’ (wl))) 
ft NoChange (closed.layout)) 

ft ((s = CLOSED) 

-> FORALL wl: Windows ( 

(w ■ wl -> closed.layout (w) [location] ■ 1 

ft closed.layout (w) [size] » closed.layout’ (w) [size] 
ft closed.layout (w) [rep] ■ closed.layout’ (w) [rep] ) 
ft (w "« wl -> closed.layout (wl) ■ closed.layout’ (wl))) 
ft NoChange (open.layout) ) , 

set_size(w: Windows, s: States, si: Sizes): BOOLEAN ■■ 

C(s = OPEN) 

-> FORALL wl: Windows ( 

(w = wl -> open.layout (w) [size] * si 

ft open_layout(w) [location] « open.layout’ (w) [location] 
ft open.layout (w) [rep] ® open_layout ’ (w) [rep] ) 
ft (w wl -> open.layout (wl) « open.layout’ (wl))) 
ft NoChange(closed_layout)) 

ft ((s = CLOSED) 

-> FORALL wl: Windows ( 

(w = wl -> closed.layout(w) [size] * si 

ft closed_layout(w) [location] » closed.layout’ (w) [location] 
ft closed.layout(w) [rep] = closed.layout’ (w) [rep] ) 
ft (w “• wl -> closed_layout(wl) = closed.layout’ (wl))) 
ft NoChange (open.layout) ) , 

update_display_close(w : Windows): BOOLEAN *■ 

(display * display’ 

SET.DIFF {SETDEF 1: Layouts (1 ■ open.layout’ (w))} 

UNION -(SETDEF 1: Layouts (1 ■ closed.layout’ (w))» , 

update_display_open(w: Windows): BOOLEAN •» 
display * display’ 

SET.DIFF {SETDEF 1: Layouts (1 *» closed.layout’ (w))> 

UNION {SETDEF 1: Layouts (1= open.layout’ (w))>. 


update_display_create(w: Windows): BOOLEAN =*= 

(state(w) = OPEN & (display = display’ 

UNION {SETDEF 1: Layouts (1 * open_layout(w))})) 

| (state(w) = CLOSED & (display = display' 

UNION {SETDEF 1: Layouts (1 « dosed_layout(w))))) , 

update_display_destroy(w: Windows): BOOLEAN *= 

(state(w) * OPEN & (display » display' 

SET.DIFF {SETDEF 1: Layouts (1 ■ open.layout’ (w) )}) ) 

| (state(w) = CLOSED ft (display * display' 

SET.DIFF {SETDEF 1: Layouts (1 » closed.layout’ (w))>)) , 

update_display_move (w: Windows): BOOLEAN =* 

(state ’(w) = OPEN ft (display = display' 

SET.DIFF {SETDEF 1: Layouts (1 s open_layout’ (w))> 

UNION {SETDEF 1: Layouts (1 * open_layout(w)))0) 

I (state’ (w) * CLOSED ft (display = display’ 

SET.DIFF {SETDEF 1: Layouts (1 = closed_layout’ (w))> 

UNION {SETDEF 1: Layouts (1 * closed_layout(w))})) 


INITIAL /* the following assertion defines the initial state of the system */ 
display = EMPTY 
ft FORALL w: Windows ( 
state (w) = UNUSED 
ft process (w) = NULL _PR0 CESS 
ft input_focus(w) » false) 
ft FORALL p: Processes ( 

OVERLAPS (INITIAL.OPEN.LAYOUT(p), BACKGROUND) 
ft OVERLAPS (INITIAL_CLOSED_LAYOUT(p) , BACKGROUND)) 

INVARIANT 

/* the following assertion is the critical correctness requirements 
that must hold in every state (including the initial state */ 

FORALL 1: Layouts ( 

1 ISIN display -> 

EXISTS w: Windows ( 

(state (w) = OPEN ft 1 * open.layout(w)) 

| (state (w) « CLOSED ft 1 * closed.layout(w)))) 
ft FORALL 1: Layouts ( 

1 ISIN display -> OVERLAPS (1, BACKGROUND)) 
ft FORALL w: Windows ( 
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SPECIAL (v) & state (w) "= UNUSED 
-> EXISTS 1: Layouts ((1 ISIN display 

ft (1 * open_layout(w) I 1 ■ closed_layout(v))) 

ft FORALL li: Layouts ((1 "° ll) ft (11 ISIN display) 
-> "OVERLAPS (11, 1)))) 

/* the transitions are written to have NoChange to the state variables 
if they shouldn’t be applied. These NoChange clauses could be 
rewritten to specify error notification and processing */ 

TRANSITION close_window(w: Windows) /* iconify */ 

EXIT 

state’ (w) = OPEN 
ft "SPECIAL (w) 
ft state (w) BECOMES CLOSED 
ft update_display_close(w) 
ft to_top_level(w) 

ALT NoChange 

TRANSITION open_window(w: Windows) 

EXIT 

state’ (w) ■ CLOSED 
ft state (w) BECOMES OPEN 
ft update_display_open(w) 
ft to_top_level(w) 

ALT NoChange 

TRANSITION destroy_window(w: Windows) 

EXIT 

(state’ (w) = OPEN I state’ (w) *= CLOSED) 
ft state(w) BECOMES UNUSED 
ft "SPECIAL (w) 

ft update_display_destroy(w) 

ALT NoChange 

TRANSITION create (p: Processes) 

EXIT 

EXISTS w: Windows ( 
state’ (w) - UNUSED 

ft state(w) BECOMES INITIAL.STATE(p) 
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ft open.layout (w) BECOMES INITIAL_CLOSED_LAYOUT(p) 
ft closed.layout (w) BECOMES INITIAL_OPEN_LAYOUT(p) 
ft process (w) BECOMES p 
ft update.display.create(w) 
ft to.top.level(w)) 

ALT HoChange 

TRANSITION shift_focus(w: Windows) 

/* assumes that only one window at a time has input focus and 
that closed windows can have input.focus */ 

EXIT 

(state* (w) = OPEN I state’ (w) = CLOSED) 
ft FORALL wi: Windows (input.focus (wl) = (wl * w)) 

ALT NoChange 

TRANSITION move(w: Windows, 1: Locations) 

EXIT 

(“SPECIAL(w) 

ft update.display.move(w) 

ft (((state’ (w) * OPEN) 

ft set_location(w, state’ (w), 1) 
ft OVERLAPS (open.layout (w) , BACKGROUND) 
ft "EXISTS wl: Windows ( 

SPECIAL (wl) ft state’ (wl) "= UNUSED 
ft OVERLAPS(open_layout(w) , open.layout’ (wl)))) 

| ((state’ (w) = CLOSED) 

ft set_location(w, state’ (w), 1) 
ft OVERLAPS (closed.layout (w) , BACKGROUND) 
ft 'EXISTS wl: Windows ( 

SPECIAL (wl) ft state’ (wl) "<* UNUSED 
ft OVERLAPS (closed.layout (w) , open.layout’ (wl)))))) 

ALT NoChange 


TRANSITION resize (w: Windows, s: Sizes) 

EXIT 

(state’ (w) = OPEN) ft 'SPECIAL(w) 
ft "EXISTS wl: Windows (SPECIAL (wl) ft (state’ (wl) '« UNUSED) 
ft OVERLAPS (open.layout (w) , open.layout ’ (wl) ) ) 
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* set_size(w, state’ (w), s) 


ALT NoChange 

TRANSITION to.f oreground(w : Windows) 

EXIT 

to.top.level(w) 

A state ’ (w) "* UNUSED 

ft "EXISTS wi: Windows (SPECIAL (wl) k (state’ (wl) "* UNUSED) 

k ((state’ (w) = OPEN) k ( OVERLAPS (open.layout ’ (w) , open.layout’ (wl))) 

I (state’ (w) « CLOSED) ft OVERLAPS (closed.layout ’ (v) , open.layout’ (wl)))) 

ALT NoChange 


END Top.Level 

END window.interface 


